上篇我們介紹了 Deployment 元件的服務架構，相信各位應該都有操作過一次了吧(沒有www)，我們已可建立出ReplicaSet多重副本的Pod，而在Deployment元件中，另有一個重要的功能，那就是～那就是～那就是～(老樣子重要的事情說三次)Rolling Update / RollBack的功能，在服務更新時進行輔助，協助目前服務的功能維持，並以Pod 狀態檢查測試新版本的功能是否正常執行。

簡介

圖片來源：https://freecontent.manning.com/deploying-and-updating-apps/

在Pod的元件的生命規劃之中，我們若需要將服務更新，則重新啟動一個新的Pod即可，但這個動作將造成服務中斷，在偉大的開發者左思右想之後～，就想到了一個透過多重副本(ReplicaSet)機制，將Pod循序進行更新(Rolling Update)的方案，並將服務逐步更新，讓網路呼叫服務的同時能夠持續保有服務基礎功能，而這樣就可保證服務更新不中斷，而反之當服務異常的通時透過回滾機制，逐步將新版本的Pod置換為舊版的Pod，對於回覆服務也同樣能夠保證服務不中斷的訴求，在上篇文章中我們提到 ReplicaSet已整併在Deployment元件之上，而Rolling Update(含Roll Back)功能在後續就直接實作在Deployment元件之上了。

Deployment

服務設計

• 服務描述檔案

使用 strategy 中 Type 設置 Rolling Update
maxSurge = 更新狀況下新增 N 個 Pod 協助更新，同時新增 N Pod / 刪除 N Pod，最多 ReplicaSet + N Pod
maxUnavailable = 最多允需 N 個 Pod 無法服務
minReadySeconds = 容器啟動後等待服務啟動時間(秒)
revisionHistoryLimit = 歷史紀錄最多更新版本保留次數

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-rollingupdate-deployment
  labels:
    app: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.12

• 執行結果
  

派送測試

• 功能指令

這邊需要加 --record 用來記錄版本(給 RollBack 參考的版本號)

k3s kubectl create -f ${deployment-file} --record

• 執行結果
  

派送驗證

• 功能指令

k3s kubectl get deployment -o wide

• 執行結果
  

Rolling Update

輔助指令

更新狀態檢查

• 功能指令

僅在 Deployment 更新時使用，更完畢的不會在返回訊息。

k3s kubectl rollout status deployment ${deployment-name}

• 執行結果
  

apply 方案

更新服務描述擋案

• 更新服務描述檔案

直接對於Deployment服務檔案進行調整

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-rollingupdate-deployment
  labels:
    app: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

• 執行結果
  

更新 deployment

• 功能指令

k3s kubectl apply -f ${deployment-name} --record

• 執行結果
  

set-image 方案

• 功能指令

更新 Pod 上 Container 的 Image版本使用

k3s kubectl set image deployment ${deployment-name} ${container-name}=${image-name}:${image-port} --record

• 執行結果
  

edit 方案

• 功能指令

kubectl edit deployment ${deployment-name} --record

• 修改內容
  
• 執行結果
  

Roll Back

輔助指令

檢視服務更新的版本

• 功能指令

k3s kubectl rollout history deployment ${deployment-name}

• 執行結果
  

回復上一版本

• 功能指令

k3s kubectl rollout undo deployment ${deployment-name}

• 執行結果
  

回復指定版本

• 功能指令

這邊需要先顯示各個版本的設定與更新內容，才可知道如何指定版本號
這邊的 N => 設定為某一版本的號碼

k3s kubectl rollout undo deployment ${deployment-name} --to-revision=N

• 執行結果
  

今天介紹了 Rolling Update & Roll Back 功能，在 k3s之中可發現它是支援kubernetes滾動更新的功能，並且完全不需要修改yaml檔案的功能，在運作法跟指令上也與 kubernetes相同，在更新方案上，apply、set-image、edit、rollout undo等方案也完全可以移植過來使用，在整體的滾動更新(Rolling Update)測試上相當的順利，後續篇幅將介紹 Deployment 的 Affinity 的親和性測試，確認 k3s 的 Worker Node是否可以接受節點標籤的設定，並嘗試使用Affinity功能管理Pod的派送節點。